Integrated circuit designs continue to increase in size and complexity, a bottom-up hierarchical design flow is becoming more common. In particular, system on a chip-type designs (“SOC”) incorporating a number of intellectual property cores (“IP cores”) are increasingly common. SOCs are devices partially or wholly integrating various computer components into a monolithic semiconductor integrated circuit or a single package carrying several interconnected monolithic integrated circuits. “Chip” includes either configuration. An IP core is a reusable unit of logic, cell, or chip layout design that can be used as building blocks along with other logic to create a chip, including SOCs. Examples of IP cores include microprocessors such as those having ARM architectures, and peripheral controllers such as those for PCI Express, SDRAM, Ethernet, or USB devices. IP cores can be available as synthesizable register-transfer level (“RTL”) in a suitable hardware description language or as physical layouts at a transistor level. IP cores are so named because an IP core is generally licensed from the vendor who is the party or entity that creates the IP core, and is licensed by the circuit designer for use in the SOC.
In a bottom-up flow the IP cores are separately designed and acquired, then integrated into an SOC. The IP core vendor can also create test patterns specific to a particular IP core, which can then be migrated for use in testing the SOC. The advantage of such an arrangement is that the test patterns are then portable along with the IP core, and may be used for any number of SOC designs incorporating that particular IP core. This simplifies test pattern generation for the SOC as a whole.
The various test patterns created or provided by the various vendors for the IP cores of the SOC do not test the interconnect logic between the IP cores. From the point of view of SOC testability, such logic should be tested. Current techniques to test the interconnect logic first confirm that the entire model of the SOC including the IP cores are built to ensure completeness. Then, each of the fault sites are accounted for within the IP cores that are already tested by the IP core-level test patterns.
The disadvantages of the above-described approach are myriad. First, as designs continue to become larger, the model size and runtime to create automated test pattern generation (“ATPG”) models also increase significantly. Depending on the size of the IP core relative to the SOC top-level logic, the runtime increase can be as high as ten- to twenty-fold by including the full IP core along with the interconnect logic during ATPG; the size of the IP core logic can be ten or more times the size of the interconnect logic. For example, an SOC having one hundred million logic gates may have ten million logic gates for boundary, interconnect, and glue logic. Creating an ATPG model for the SOC that includes IP core internal logic gates in addition to the interconnect and glue logic results in a large and complex model, and thus model size and runtime for ATPG are larger than is really necessary. Second, the accuracy of the true interconnect fault coverage is reduced because there is a significant amount of bookkeeping involved for the faults within each IP core; it is not trivial to know which faults should be considered part of the interconnect and which should be part of the IP core internal logic. Third, simulation of the SOC test patterns require huge databases and runtimes. Fourth, delay-annotated simulation is not possible currently without a complete SOC model first being built. Fifth, some IP cores provided by third-parties may not have a full ATPG model due to the third-parties' concerns about protecting their intellectual property, limiting test pattern generation. Sixth, in the above approach, there is no automated generation of testmode setup and ATPG protocol files. Finally, as more and more circuit designs move towards three-dimensional designs having stacks of integrated circuits, developing complete ATPG models for all the embedded dies will become infeasible due to the further increased model size.
One approach that attempts to address these disadvantages is the Interface Logic Model (“mM”). ILM is a concept used in the areas of timing and physical design where gate-level representations of a physical block are used in hierarchical design flows; only the connections from the input to the first level of flip-flops, and the connections from the last stage of flip-flops to the outputs are represented. All other internal flip-flop to flip-flop paths are stripped out in an ILM, such that the ILM is like a black box. For very large chips, using an ILM for all embedded blocks can be a more efficient alternative to a full netlist representation. For static timing analysis (“STA”), if it is infeasible to run STA on the full design, then STA can be run at the block-level for the intra-block paths. Chip-level STA can use ILMs for the inter-block paths. The advantage of ILM for STA is that the entire clock-to-clock path is visible at the top level for interface nets, unlike a traditional block-based hierarchical implementation flow. This gives better accuracy in analysis for interface nets at a negligible increase in overhead due to additional memory and runtime. However, an ILM is insufficient and over-simplified when used for hierarchical design for test (“DFT”), since it is neither complete nor accurate for ATPG. For example, leading companies have attempted to extend ILM for SOC testing, but have found this technique to encounter large numbers of serious problems at the level of the test floor due to extensive miscompares caused by the use of the incomplete and inaccurate ATPG models. Thus, a way to create a more complete and accurate model that still reduces the amount of logic being modeled for an IP core is needed.